home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14894 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  98 lines
  1. Newsgroups: comp.object,comp.lang.c++,comp.lang.java
  2. Path: newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: Re: Java: What's the Big Deal?  (GC)
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Tue, 2 Apr 1996 15:15:45 GMT
  8. Message-ID: <1996Apr2.151545.28720@schbbs.mot.com>
  9. References: <MARKT.96Apr1200203@atlas.harlqn.co.uk>
  10. Sender: news@schbbs.mot.com (SCHBBS News Account)
  11. Nntp-Posting-Host: 129.188.128.126
  12.  
  13. In article <MARKT.96Apr1200203@atlas.harlqn.co.uk> markt@harlqn.co.uk (Mark  
  14. Tillotson) writes:
  15. > shang@corp.mot.com (David L. Shang) wrote:
  16. > > 
  17. > > The more a program depends on GC, the more likely it will exhaust memory;
  18. > > because the storage is collected only when all its references are
  19. > > no longer valid, not at the time when all its references are no longer
  20. > > used. 
  21. > In complex software this is not true...  explicit management of
  22. > storage places such a burden on the programmer that either security is
  23. > compromised (catastrophic bugs) or space leaks occur (that a GC would
  24. > easily have caught).
  25.  
  26. I did not mention that explicit management of storage is better.
  27. On the contrary, it should be avoided unless it is absolutely
  28. necessary. However, GC is not always better in terms of efficiency
  29. and memory economy, compared to by-value variables. By-value variables
  30. are not explicit. They cannot be be allocated/deallocated explicitly.
  31. The management of storage is done usually by the compiler, linker,
  32. loader, or the run-time system.
  33.  
  34. > In a GC-based system you only have to debug the
  35. > GC, not every single program that calls free() !!
  36. > 
  37.  
  38. No really true. You still have the risk of dangling resources,
  39. invalid references, unless you prohibit the program to process
  40. resources such as files, persistent objects, and network resources.
  41.  
  42. > > Be careful, never make a variable's lifetime unecessarily longer
  43. > > than the required.
  44. > This advice for avoiding space leaks happens to be valid _whether or
  45. > not_ automatic GC is in operation!
  46. > 
  47. Using automatic GC is helpful, but not a complete solution to
  48. all kinds of resources.
  49.  
  50. > > With Java's array, memory will be smashed into millions of small
  51. > > pieces. Here is a brief comparison:
  52. > 
  53. > <array of struct of 3 floats example omitted>
  54. > 
  55. > On many machines one load instruction is cheaper than multiplying an
  56. > index by 3, so Java's approach is actually faster.
  57.  
  58. How? Note that Java's array element must contain two references: one
  59. to the type of the element and another to the object. Therefore,
  60. multiplying an index by 8 must be performed first then adding an shift
  61. (4) for locating the object reference, and then a load instruction
  62. can be performed. If it is a two or three dimension array, such procedure
  63. must be done two are three times.
  64.  
  65. > equal)... Object allocation rarely costs a significant proportion of
  66. > execution time, unless the application fails to do anything useful
  67. > with what it allocates!!
  68.  
  69. One or two object allocations cost nothing, I agree. But millions of
  70. millions will do!
  71.  
  72. Performance is not the only issue. Another problem is
  73. the object transfer from one address space to another, for example,
  74. from one computer to another on the network, or from memory to disk.
  75. If smart reference is the only choice for object, there is no easy
  76. way to do things like network programming.
  77.  
  78. I am not saying that GC is bad. It is good, but it is not enough.
  79. Therefore, it should not be the only choice.
  80.  
  81. I am not saying that C++ pointers are good It is bad, but sometimes
  82. you have to use them for the sake of others not using them (e.g., to
  83. implement smart references).
  84.  
  85. By-value variables (or static references) are not C++ pointers. They
  86. are equally safe as smart references. They are required not just for
  87. performance, but for object transfer from one address space to a
  88. different address space.
  89.  
  90. There many many other kinds of object references that GC can not
  91. handle, for example, netword reference, references to clones,
  92. persistent object reference, etc. Without them, processing resources
  93. can never be safe.
  94.  
  95. David Shang
  96.  
  97.  
  98.